Unified data packet for encapsulating data packets having diverse formats

ABSTRACT

Embodiments of the present invention described and shown in the specification and drawings facilitate the transportation of data packets having diverse formats through a general packet switching system. Due to the diverse formats of the data packets used by various common communications protocols, it is has been difficult to produce general packet switching systems that are able to switch multiple protocols. Embodiments of the present invention provide a Unified Data Packet for encapsulating data packets having diverse formats. Through encapsulation, embodiments of the present invention improve switching system efficiency by providing a single data packet format for handling by the switching system while enabling data packets in diverse formats to pass through the switch.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority under 35 U.S.C. §119(e) to U.S.Provisional Application No. 60/227,477, filed Aug. 24, 2000, theentirety of which being incorporated herein by reference.

BACKGROUND OF THE INVENTION

[0002] The present invention generally relates to packet-based switchingsystems, and more particularly to methods, apparatuses, mediums, andsignals for facilitating the transmission of data packets having diverseformats through switching systems.

DESCRIPTION OF THE RELEVANT ART

[0003] A number of different packet-based data transmission protocolsare in commercial use. While packet-based switching systems dedicated toparticular protocols are common, it has been more difficult to producegeneral packet switching systems that are able to switch multipleprotocols. This is partially due to the diverse formats of the datapackets used by the various protocols.

SUMMARY OF THE INVENTION

[0004] Embodiments of the present invention described and shown in thespecification, claims, and drawings facilitate the transportation ofdata packets having diverse formats through general packet switchingsystems.

[0005] An object of the present invention is to provide a uniform formatfor encapsulating the diverse data packet formats generated by variouspacket-based data transmission protocols. An advantage of the presentinvention is the improvement in switching efficiency resulting from theuse of the particular embodiments of uniform data packet encapsulationformats of the present invention.

[0006] In some embodiments of the present invention a frame (alsoreferred in this specification as a “Unified Data Packet”) is stored inthe computer-readable medium of computer systems, includingpacket-switching computer systems, or is transported on communicationssystems between or within computer systems. A particular embodiment ofthe Unified Data Packet of the present invention is referred to in thisspecification as the “Fairfax Frame.” Embodiments of the Unified DataPacket comprise a Header Section, a Payload Section, and a TrailerSection. The Header Section comprises a Segment Type field and a FinalPayload Count Valid field. The contents of the Segment Type field andthe contents of the Final Payload Count Valid field are responsive tothe contents of the Payload Section. The Header Section may alsocomprise a Service Type field, a Routing Identification field, and/or aSource Identification field. Embodiments of the Unified Data Packet mayfurther comprise, responsive to the contents of the Final Payload CountValid field, a Final Payload Count field in the Payload Section.Complete or partial data packets for transport using the Unified DataPacket of the present invention are stored in the Payload Section.Furthermore, the Unified Data Packet of the present invention maycomprise two Header Sections, each with an associated Payload section.

[0007] Additional objects and advantages of the invention are set forthin part in the description which follows, and in part are obvious fromthe description, or may be learned by practice of the invention. Theobjects and advantages of the invention may also be realized andattained by means of the instrumentalities and combinations particularlyset out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The accompanying drawings, which are incorporated in andconstitute part of the specification, illustrate preferred embodimentsof the invention, and together with the description, serve to explainthe principles of the invention.

[0009] In the accompanying drawings:

[0010]FIG. 1 is a diagram depicting an embodiment of a Unified DataPacket of the present invention for encapsulating data packets havingdiverse formats.

[0011]FIG. 2 is a diagram depicting an embodiment of a Fairfax Frame ofthe present invention.

[0012]FIG. 3 is a diagram depicting an embodiment of a Header Section ofa Fairfax Frame of the present invention.

[0013]FIG. 4 is a diagram depicting an embodiment of a Payload Sectionof a Fairfax Frame of the present invention.

[0014]FIG. 5 is a diagram depicting an embodiment of a Trailer Sectionof a Fairfax Frame of the present invention.

[0015]FIG. 6 is a diagram depicting an embodiment of a Fairfax DualRouting Packet of the present invention.

DETAILED DESCRIPTION

[0016] Interpretation of Terms

[0017] Unless otherwise noted in this specification or in the claims,all of the terms used in the specification and the claims will have themeanings normally ascribed to these terms by workers in the art. Certainterms specifically comprise the meanings associated with them asfollows:

[0018] “Computer system” refers to individual standalone computers,multiple computers coupled in any manner, and software simulations ofcomputers regardless of the intended use of the computer system or thetechnology used to implement the computer system. The term “Computersystem” includes, but is not limited to, packet-switching systems andother communications switching systems.

[0019] “Data packets” refers to any data packets used by any computercommunications protocol, and includes synchronous (including TimeDivision Multiplex (TDM)) data packets and asynchronous (including HighLevel Data Link Control (HDLC)) data packets.

[0020] Detailed Description

[0021] Acts performed by methods and apparatus functions of the presentinvention may be implemented, as is known in the art, as softwarerunning on general purpose computers or special purpose computers, ashardware, or as combinations of software and hardware.

[0022] The data packets produced by various computer communicationsprotocols generally vary widely in format, including size. Due to thisnon-uniformity, it may be difficult and inefficient to switch datapackets having diverse formats through a general purpose packet switch.The present invention facilitates such switching by encapsulating all ofthe data packets to be switched (sometimes referred to as “transporteddata packet”) into a Unified Data Packet format. Embodiments of theUnified Data Packet contain a Header Section, a Payload Section, and aTrailer Section. These embodiments are uniform in overall size, and inthe arrangement and purpose of the data fields contained in the HeaderSection and Trailer Section. The arrangement of the Payload Section,which carries all or a portion of a data packet to be switched, varies,as described below, depending on the data packet being carried. Theuniform size of the Unified Data Packet, and the generally uniformarrangement and purpose of the fields within the Unified Data Packetenables Unified Data Packets to be switched efficiently.

[0023] In the embodiment of Unified Data Packet 101 depicted in FIG. 1,Unified Data Packet 101 comprises Header Section 105, Payload Section110, and Trailer Section 115. Embodiments of Trailer Section 115comprise the various fields used for routing and managing data packetsand contained in data packet trailers as are known in the art. In someembodiments of the present invention, for example, Trailer Section 115will contain a single field used in conjunction with error checking, asis known in the art, such as a checksum or a Bit Interleaved Parityvalue.

[0024] In some embodiments, depending on the size of the transporteddata packet and as described below in connection with the Final PayloadCount Valid Field, Payload Section 110 comprises a single, fixed-lengthfield containing all or part of a transported data packet; while inother embodiments Payload Section 110 comprises a fixed-length FinalPayload Count field 111 in addition to a fixed-length field containingall or part of a transported data packet.

[0025] Embodiments of Header Section 105 comprise the various fields, asare known in the art, for routing and managing data packets. Embodimentsof Header Section 105 also comprise fields for indicating Segment Typeand Final Payload Count Valid. If a transported data packet is ofexactly the same length as fixed-length Payload Section 110, then theSegment Type field is set to indicate that Payload Section 110 containsa complete transported data packet and the Final Payload Count Validfield is set to indicate that Payload Section 110 does not contain aFinal Payload Count field 111. If a transported data packet is smallerthan the fixed-length Payload Section 110, then the Segment Type fieldis set to indicate that Payload Section 110 contains a completetransported data packet, the Final Payload Count Valid field is set toindicate that Payload Section 110 contains a Final Payload Count field111, and the Final Payload Count field 111 contains the length of thetransported data packet.

[0026] If a transported data packet is larger than the fixed-lengthPayload Section 110, then the transported data packet must betransported by two or more Unified Data Packets 101. In the Unified DataPacket 101 containing the initial portion of the transported datapacket, the Segment Type field is set to indicate that Payload Section110 contains the initial part of the transported data packet and theFinal Payload Count Valid field is set to indicate that Payload Section110 does not contain a Final Payload Count field 111. In the UnifiedData Packet 101 containing a middle part of the transported data packet,the Segment Type field is set to indicate that Payload Section 110contains a middle part of the transported data packet and the FinalPayload Count Valid field is set to indicate that Payload Section 110does not contain a Final Payload Count field 111. Some embodiments ofHeader Section 105 will contain a Sequence Number field, as is known inthe art. In some embodiments, the Sequence Number field is set to zeroin a Unified Data Packet 101 containing a complete or initial part of atransported data packet. The Sequence Number field is incremented by onein each subsequent Unified Data Packet 101 containing a middle part orfinal part of a transported data packet. Thus, the initial, middle, andfinal portions of a transported data packet will contain sequentialnumbers in the Sequence Number fields of the Unified Data Packets 101carrying the transported data packet and the order of the portions canbe determined, as is known in the art, so that the transported datapacket portions can be extracted from the Unified Data Packets 101 andcorrectly reassembled. Other methods of determining the correct order ofpackets sent through communications systems are known in the art and maybe employed.

[0027] Finally, in the Unified Data Packet 101 containing the final partof the transported data packet, the Segment Type field is set toindicate that Payload Section 110 contains the final part of thetransported data. If the final part of the transported data packet issmaller than the fixed-length Payload Section 110, then the FinalPayload Count Valid Field is set to indicate that Payload Section 110contains a Final Payload Count field 111, and the Final Payload Countfield 111 contains the length of the final part of the transported datapacket. If the final part of the transported data packet is the samesize as the fixed-length Payload Section 110, then the Final PayloadCount Valid Field is set to indicate that Payload Section 110 does notcontain a Final Payload Count field 111.

[0028] A detailed example of one embodiment of the present invention isprovided as follows:

[0029] Fairfax Frame 201

[0030] The Fairfax Frame is the Ocular Networks, Inc., (ONI) Fairfax,Va., proprietary format for encapsulating user Time Division Multiplex(TDM) traffic, Asynchronous Transfer Mode (ATM) Cell or IP packet,configuration information, and Operation, Administration and Maintenance(OA&M) information into a packet to be switched through a packet-basedswitching fabric. Ocular products using the Fairfax Frame are referredto herein as “Ocular Switching Equipment.” An exemplary format for aFairfax Frame 201 is shown in FIG. 2. Fairfax Frame 201 comprises aFairfax Header Section 205, which is 8 bytes in size, a Fairfax PayloadSection 210, which is 63 bytes in size (including one byte for FinalPayload Count field 111), and a Fairfax Trailer Section 215, which isone byte in size.

[0031] Fairfax Header Section 205

[0032] The header fields are as depicted in FIG. 3 and described in moredetail below.

[0033] Version 301

[0034] Size: 1 bit.

[0035] Usage: The Version (VER) field 301 is provided to permit futureupgrades to the Fairfax Frame 201 format. Value Description 0 Version0 - initial value. 1 Version 1 or higher - future value.

[0036] The field is loaded at every place where Fairfax Frames 201 aregenerated, and checked at every place where Fairfax Frames 201 arereceived and interpreted:

[0037] All Ocular switching equipment must recognize and interpret aVersion 0 frame.

[0038] Version 1+ equipment can use the bit to determine the FairfaxFrame 201 capability of the generating equipment.

[0039] If Version 0 compatible equipment receives a Version 1+ frame,the frame should be counted and discarded.

[0040] The VER field 301 is only one bit because a Version 1+ FairfaxFrame 201 can define additional version bits to accommodate furtherframe versions.

[0041] Unused Values: There are no unused values.

[0042] Multicast 302

[0043] Size: 1 bit.

[0044] Usage: The Multicast (MCST) field 302 indicates whether the framehas a single (unicast) or multiple (multicast) destination(s): ValueDescription 0 Frame is unicast, i.e. will be switched to a single egressport. 1 Frame is multicast, i.e. will be switched to multiple egressports.

[0045] The MCST field 302 will always be loaded when a Fairfax Frame 201is created. However, the value may not be used since the frame'sdestination(s) will be identified by indexing a routing table with theFairfax Routing ID. The MCST field 302 provides a direct indication ofthe multicast status for debugging purposes.

[0046] Unused Values: There are no unused values.

[0047] Segment Type 304

[0048] Size: 2 bits.

[0049] Usage: The Segment Type (ST) field 304 indicates which part of auser datagram is carried in the Fairfax Payload section 210. The fourvalues are interpreted as follows: Value Description 10 Beginning OfFrame (BOF) 00 Continuation Of Frame (COF) 01 End Of Frame (EOF) 11Single Segment Frame (SSF)

[0050] BOF, COF and EOF are applied to Fairfax Frames 201 which carrypart of a segmented datagram. SSF is applied to a Fairfax Frame 201which carries a complete user datagram.

[0051] When a segment type error is detected, the erroneous segmentshould be counted and discarded.

[0052] Unused Values: There are no unused values.

[0053] Final Payload Count Valid 303

[0054] Size: 1 bit.

[0055] Usage: The Final Payload Count Valid (FPCV) field 303, togetherwith the header ST field 304 and the first byte of the Fairfax Payloadsection 210 (known as the Final Payload Count (FPC) 111), indicates thenumber of valid data bytes in the payload section: ST FPCV Value ValueDescription BOF 0 User datagram information completely fills the FairfaxPayload section 210. 1 Invalid, a BOF segment must contain a fullpayload. When such a frame is detected it should be counted anddiscarded. COF 0 User datagram information completely fills the FairfaxPayload section 210. 1 A user datagram error has been detected at theingress to the network and no further segmentation of the datagram willbe performed. EOF 0 The end of the user datagram completely fills theentire Fairfax Payload section 210. 1 The FPC field 111 contains a countof the number of payload bytes (1-63) which contain the end of the userdatagram. SSF 0 The user datagram completely fills the entire FairfaxPayload section 210. 1 The FPC field 111 contains a count of the numberof payload bytes (1-63) which contain the entire user datagram.

[0056] The FPCV field 303 prevents the need to add a segment to adatagram just to carry the payload count for a full Fairfax Payloadsection 210.

[0057] This scheme only supports user datagrams which are an integernumber of bytes in length.

[0058] Unused Values: There are no unused values.

[0059] Sequence Number 305

[0060] Size: 3 bits.

[0061] Usage: The Sequence Number (SN) field 305 provides protection fordatagrams segmented into multiple Fairfax Frames 201:

[0062] When a user datagram is segmented, the SN field 305 in eachconsecutive frame is set to an incrementing, modulo 8 number (0-7, 0 . .. ). The SN field 305 will be set to 0 (zero) for the first frame ofevery datagram.

[0063] When a frame carries a complete user datagram, the SN field 305is set to zero. Any other SN value is invalid.

[0064] Some system implementations cannot transmit or receive FairfaxFrames 201 out of order. Therefore an error in the Fairfax Frame SNfield 305 indicates a dropped frame. When a Fairfax Frame sequencenumber error is detected, the erroneous frame should be counted anddiscarded.

[0065] Unused Values: There are no unused values.

[0066] Reserved 306

[0067] Size: 8 bits.

[0068] Usage: The Reserved (RES) field 306 is available to increase thesize of the Fairfax Routing Identifier fields 307, 308 and/or includeadditional control fields in future versions of the Fairfax Frameformat. At the time of writing, the field is unused and the value willbe set to 00H.

[0069] Unused Values: RES values of 01H-FFH are currently invalid. Untilthe field usage is defined, frames with invalid RES values should becounted but not discarded. The counter should include an enable/disablefunction so that future versions of the Fairfax Frame 201 can implementa RES field value of 00H without being counted.

[0070] Fairfax Header 205 contains an additional reserved field 313.This field is not currently used.

[0071] Fairfax Routing Identification 307, 308

[0072] Size: 16 bits. As would be understood by one skilled in the art,the Fairfax Routing Identification (FRID) value is located in twofields—FRID field 307 contains the Most Significant Byte (MSB); FRIDfield 308 contains the Least Significant Byte (LSB).

[0073] Usage: The FRID fields 307, 308 identify the frame's path throughthe Ocular switching equipment between the ingress and egress ports.

[0074] Fairfax Routing Identification (FRID) in the Fairfax headerprovides the logical routing information for transporting the payloadfrom an ingress port to an egress port. Multiple FRIDs can be assignedto one ingress port for establishing multiple connections to severaldifferent egress ports.

[0075] The FRID is a “virtual” value which represents a unidirectionalpath through the Ocular switching equipment from an ingress port to anegress port. A bidirectional path through the Ocular switching equipmentwill have two FRID values assigned, one for each direction.

[0076] When the Ocular switching equipment needs to determine thedetails of the frame's path (e.g. identify the ingress and egress ports)the FRID value will index into routing table(s) which will return therequired results, as is known in the art.

[0077] The 16-bit FRID fields 307, 308 can identify a maximum of 65,536unidirectional paths or 32,768 bi-directional paths through the Ocularswitching equipment. For TDM ports which encapsulate multiple DigitalSignal level 1s (DS1s), there is one FRID assigned to each DS1. Thisvalue represents the ingress port, egress port and the location of theDS1 within the encapsulating egress datagram.

[0078] Unused values: Frames with unused FRID values will be counted anddiscarded.

[0079] Datagram Reassembly Identification

[0080] Together with the First in First Out (FIFO) data transfermechanism used to pass datagrams through the Ocular switching equipment,the FRID 307, 308, ST 304, and SN 305 fields provide sufficient datagramidentification to permit an egress Input Output Board (IOB) toreassemble multiple segmented datagrams from multiple ingress IOBs.

[0081] At any one time, an egress IOB can only be reassembling onedatagram from each Ocular switching equipment ingress port. The FRIDfields 307, 308 identify the source port (and so the original datagram)and the ST 304 and SN 305 fields identify the constituent segments. Notethat a multicast datagram may be simultaneously reassembled once on eachof multiple egress IOBs.

[0082] Source Slot Identification 309

[0083] Size: 5 bits.

[0084] Usage: The Source Slot Identification (SSID) field 309 identifiesthe switching system chassis and slot which generated the Fairfax Frame201. Bit Description 4 Identifies the chassis. A 0 (zero) identifies thefirst, or only chassis. A 1 (one) identifies the second chassis in atwo-chassis installation. 3-0 Identifies the slot within the chassis. Achassis will hold up to 14 IOBs and two NCBs, with both types of boardscapable of generating Fairfax Frames 201.

[0085] The SSID field 309 will always be loaded when a Fairfax Frame 201is created. However, the value may not be used by any switching systemfunction since the frame's source slot will be identified by indexing arouting table with the FRID 307, 308. The SSID field 309 provides adirect indication of the switching system source slot for debuggingpurposes.

[0086] Unused Values: Since the number of installed chassis, NetworkControl Boards (NCBs) and IOBs is variable, determination of valid slotvalues will be configured. Frames with invalid SSID values will becounted and discarded. An NCB provides the control and switchingfunctions to interconnect the traffic between IOBs.

[0087] Source Port Identification 310, 311

[0088] Size: 5 bits. As would be understood by one skilled in the art,the Source Port Identification (SPID) value is located in twofields—SPID field 310 contains the Most Significant Byte (MSB); SPIDfield 311 contains the Least Significant Byte (LSB).

[0089] Usage: The SPID fields 310 and 311 identify the port thatgenerated the Fairfax Frame 201. The field value is local to each IOB orNCB and starts counting from 0 (zero) for the first port.

[0090] For IOB-sourced frames, the lowest numbered SPID values refer tothe physical ports on the board. Port number 31 is assigned totest/debug frames generated from the supervisory processor.

[0091] All NCB-sourced frames are generated by the supervisory processorand so will be assigned to port number 31.

[0092] The SPID fields 310 and 311 will always be loaded when a FairfaxFrame 201 is created. However, the value may not be used by anyswitching system function since the frame's source port will beidentified by indexing a routing table with the FRID. The SPID fields310 and 311 provide a direct indication of the switching function sourceport for debugging purposes.

[0093] Source Port Identification (SPID) and Source Slot Identification(SSID) provide the information on where the Fairfax frames originated(frame origination location). It can provide information fortroubleshooting. For example, SPID, SSID together with Forward Taggingcan allow an egress port quickly to identify the source of congestion.

[0094] Unused Values: The currently identified IOBs have at most 28ports (on the DS1 IOB). Therefore SPID values of 28-30 are unused butcould be used in the future. All remaining SPID values will beconfigured based on the type of IOB or NCB. Frames with invalid SPIDvalues will be counted and discarded.

[0095] Discard Priority 312

[0096] Size: 1 bit.

[0097] Usage: The Discard Priority (DP) 312 field is used in congestionsituations, where it indicates the discard priority for the frame.

[0098] A value of 1 (one) indicates that the frame is discard priority,a value of 0 (zero) indicates that the frame is not discard priority. Ina congestion situation, discard priority frames will be discarded inpreference to non-discard priority frames.

[0099] At an ingress port, any discard priority indication included inthe incoming datagrams will be copied into the DP bit 312. At an egressport, the DP bit 312 will be copied into the appropriate datagram field.

[0100] The DP bit 312 can be set by the datagram originator, bypreceding network elements, or anywhere within the Ocular switchingequipment where policing is being performed.

[0101] Unused Values: There are no unused values.

[0102] Forward Tag 315

[0103] Size: 1 bit.

[0104] Usage: Forward Tag Congestion Notification or “Forward Tagging”(FTAG) 315 is set to 1 (one) by the Ocular switching equipment toindicate that congestion is being experienced for traffic in thedirection of the Fairfax Frame 201 carrying the FTAG 315 indication.Thus, FTAG 315 indicates to the frame destination that congestion wasexperienced along the frame's path through the Ocular switchingequipment.

[0105] At an ingress port, any congestion indications included inincoming datagrams are carried transparently through the Ocularswitching equipment. The congestion values are not copied to the Fairfaxheader FTAG field 315. At an egress port, if the Fairfax header FTAGfield 315 is set to 1 (one), the value will be copied into theappropriate outgoing datagram field to indicate congestion in thedatagram path.

[0106] The FTAG bit can be set to 1 (one) anywhere there is policing orqueuing within the Ocular switching equipment.

[0107] Unused Values: There are no unused values.

[0108] Backward Tag Congestion Notification 314

[0109] Size: 1 bit.

[0110] Usage: Backward Tag Congestion Notification or “Back Tagging”(BTAG) 314 is set to 1 (one) by the Ocular switching equipment toindicate that congestion is being experienced for traffic in theopposite direction of the Fairfax Frame 201 carrying the BTAG 314indication. Thus, BTAG 314 indicates to the frame source that congestionwas experienced for frames being transmitted by the source.

[0111] At an ingress port, any congestion indication included inincoming datagrams are carried transparently through the Ocularswitching equipment. The congestion values are not copied to the Fairfaxheader BTAG field 314. At an egress port, if the Fairfax header BTAGfield 314 is set to 1 (one), the values will be copied into theappropriate outgoing datagram field to indicate congestion in thedatagram path.

[0112] The BTAG bit can be set to 1 (one) anywhere there is policing orqueuing within the Ocular switching equipment.

[0113] BTAG is used within Ocular switching equipment to signal a needto reduce the amount of traffic being passed into the congestedfunction. However, there are a number of issues with BTAG which mayresult in the field being deleted from the header:

[0114] Many protocols do not include a BTAG-type indication in theirheader/trailer fields. These protocols support sender data ratereduction by transmitting higher-layer protocol messages from thereceiver, which receives the forward congestion indication, to thesender.

[0115] For those protocols which do support BTAG, the sender is notalways required to reduce the transmitted datagram flow.

[0116] BTAG does not easily apply to multicast frames because someegress queues/ports may be congested and some may be uncongested.

[0117] The BTAG field 314 has been located adjacent to the unused headerbits, so that the fields can be merged in the event that BTAG is removedfrom the Fairfax Header 205.

[0118] Unused Values: There are no unused values.

[0119] Fairfax Service Identification 316

[0120] Size: 8 bits.

[0121] Usage: The Fairfax Service Identification (FSID) field 316identifies the type of datagram, type of service, or owner of thedatagram carried in the payload section.

[0122] Example datagram and service types are:

[0123] TDM DS1

[0124] Encapsulating Digital Signal level 0s (DS0s)

[0125] Clear channel

[0126] TDM Virtual Tributary VT1.5 (VT1.5)

[0127] TDM DS3

[0128] Encapsulating DS1s

[0129] Clear channel

[0130] TDM Synchronous Transport Signal level 1 (STS-1) SynchronousPayload Envelope (SPE)

[0131] IP Access Concentration

[0132] IP encapsulation over Asynchronous Transfer Mode (ATM) AdaptationLayer 5 (AAL5)

[0133] ATM Multiplexing

[0134] Configuration

[0135] Operations Adminstration and Maintenance (OAM)

[0136] When the FSID identifies the owner of the payload data, e.g. anInternet Service Provider (ISP), the value represents a complete packageof processing and prioritizing to be applied to the payload.

[0137] Unused Values: Frames with unused FSID values will be counted anddiscarded.

[0138] Fairfax Queue Identification 317

[0139] Size: 8 bits.

[0140] Usage: The Fairfax Queue Identification (FQID) field 317identifies the egress queue/priority for the datagram carried in thepayload section.

[0141] Example queue/priority types include:

[0142] TDM Circuit Assurance

[0143] ATM Service Categories

[0144] Constant Bit Rate (CBR)

[0145] real time Variable Bit Rate (rt-VBR)

[0146] non-real time Variable Bit Rate (nrt-VBR)

[0147] Unspecified Bit Rate (UBR)

[0148] Configuration

[0149] OAM

[0150] Transmit Last

[0151] TDM Circuit Assurance is applied to TDM traffic. Frames with thisFQID priority are transmitted to meet the DS1 and DS3 timingrequirements through the Ocular switching equipment.

[0152] OAM is applied to Ocular switching equipment internal trafficcontrol which may need to be switched even in the event of user datagramcongestion.

[0153] Configuration is subdivided into at least two sub-priorities,code downloads (lower priority) and routing table updates (higherpriority).

[0154] Transmit Last is the lowest priority and is only transmitted froman egress queue when no other FQID types are present.

[0155] In addition to these queue types, the FQID value assigned at theingress port may reflect any priority values contained in the incomingdatagram.

[0156] Unused Values: Frames with unused FQID values will be counted anddiscarded.

[0157] Fairfax Payload Section 210

[0158] The Fairfax Payload Section 210 is depicted in FIG. 4.

[0159] Size: 63 bytes.

[0160] Usage: The payload section carries the user datagram.

[0161] If the datagram to be transferred is no larger than the payloadsection, the entire datagram is carried in one Fairfax Payload Section210.

[0162] If the datagram to be transferred is larger than the FairfaxPayload Section 210, the datagram will be segmented into multiplesubframes. The subframes for a particular datagram may be transferredconsecutively or interleaved with segments from other ports and/or 1OBs,datagrams from the same port will not be interleaved.) Interleavingbetween ports is supported to allow ingress IOBs to send data to theassociated egress IOB(s) as the data arrives and fills the FairfaxPayload Sections 210, reducing the need to buffer complete datagramsbefore forwarding them.

[0163] Unused Values: If a datagram does not completely fill the payloadsection, the unused bytes do not have to be set to 0 and can be anyvalue.

[0164] Final Payload Count 111

[0165] Size: 8 bits.

[0166] Usage: The Final Payload Count (FPC) field 111 contains a countof the number of payload bytes which contain user datagram information.

[0167] If a datagram does not fill the entire payload section in thelast, or only, (sub)frame then the header FPCV field 303 is set to 1(one) and the first byte of the Fairfax Payload Section 210 becomes theFinal Payload Count (FPC) field 111. This field contains a count of thenumber of payload bytes (1-63) which contain user datagram information.

[0168] The unused payload bytes (potentially all but two bytes in thepayload section) take up available bandwidth.

[0169] If a datagram completely fills the last, or only, (sub)frame thenthe header FPCV field 303 is set to 0 (zero) and the first byte of theFairfax Payload Section 210 is a valid datagram byte.

[0170] Unused Values: 0 (zero) is unused because this indicates that theprevious Fairfax Payload Section 210 was completely filled by the end ofthe datagram. 64-255 are unused because they indicate more validdatagram bytes than fit in a Fairfax Payload Section 210. For all unusedvalues, the frame will be counted and discarded.

[0171] Fairfax Trailer Section 215

[0172] The trailer section comprises a single field as depicted in FIG.5.

[0173] Bit Interleaved Parity (8-bit) 501

[0174] Size: 8 bits.

[0175] Usage: The Bit Interleaved Parity (8 bit) (BIP-8) field 501contains the result of taking each frame header and payload byte andperforming a parity calculation on each bit position as is known in theart. The BIP-8 value will reflect an odd parity calculation, i.e. theBIP-8 value will be set so the total number of ‘1’ bits in each positionis odd.

[0176] When a BIP-8 error is detected, the frame will be counted anddiscarded.

[0177] In another embodiment of the present invention, shown in FIG. 6,a Fairfax Dual Routing Packet 601 is provided. A Fairfax Dual RoutingPacket 601 is a packet that carries two Fairfax Routing IDs (FRIDs) withtheir associated payloads. A First FRID (MSB) 607 and a First FRID (LSB)608 are associated with a first payload 610. First FRID 607, 608 arepart of first Fairfax header 605. A second FRID (MSB) 667 and a secondFRID (LSB) 668 are associated with a second payload 630. Second FRID667, 668 are part of second Fairfax header 625. The original Fairfaxpayload is divided into two parts: the first part is for First FairfaxHeader 605 and First Payload 610, and the second part is for SecondFairfax Header 625 and Second Payload 630. The remaining bytes of the8-byte First and Second Fairfax Headers 605, 625 are substantially thesame as described above for Fairfax Header 205, as shown in FIG. 3. Acode in the Service Type field (First FSID 643 and Second FSID 646) ofthe First and Second Fairfax Headers 605, 625 is used to indicate thatthe Fairfax packet is a Fairfax Dual Routing Packet.

[0178] As an example, the Second Fairfax Header 625 is located startingfrom the 36th byte as shown in FIG. 6. Because only a single segmentframe is carried, no final payload count byte is required. In otherwords, each Header Section is followed by its Payload Section.

[0179] By examining the Service Type field First and Second FSID 643,646 in Headers 605, 625, the Fairfax packet processor is able toidentify each individual routing ID with its associated payload, and toroute the two payloads 610 and 630 to separate destinations. In thisembodiment, the size of a payload is a predetermined value that is inFirst and Second FSID 643, 646, such as 27 bytes. In this embodiment,the size of the payload is specified in FSID 643, 646 rather thanthrough FPCV 303. A Fairfax Trailer 615 is used that is the same asTrailer Section 215 depicted in FIG. 5.

Conclusion

[0180] It should be understood that the preceding is merely a detaileddescription of some examples and embodiments of this invention and thatnumerous changes to the disclosed embodiments can be made in accordancewith the disclosure herein without departing from the spirit or scope ofthe invention. The preceding description, therefore, is not meant tolimit the scope of the invention.

We claim:
 1. A method for transporting data, comprising: encapsulatingdata in a frame, wherein the frame comprises a header section, a payloadsection, and a trailer section, and wherein the header section comprisesa Segment Type field and a Final Payload Count Valid field, and whereinthe payload section contains the data; setting, responsive to the data,the Segment Type field and the Final Payload Count Valid field;transporting the frame through a communication system; and extractingfrom the transported frame, responsive to the Segment Type field and theFinal Payload Count Valid field, the data from the payload section. 2.The method for transporting data of claim 1, wherein the contents of thepayload section comprise, responsive to the Final Payload Count Validfield, a Final Payload Count field, and wherein extracting the data fromthe payload section is further responsive to the Final Payload Countfield.
 3. An apparatus for transporting data, comprising: means forencapsulating data in a frame, wherein the frame comprises a headersection, a payload section, and a trailer section, and wherein theheader section comprises a Segment Type field and a Final Payload CountValid field, and wherein the payload section contains the data; meansfor setting, responsive to the data, the Segment Type field and theFinal Payload Count Valid field; means for transporting the framethrough a communication system; and means for extracting from thetransported frame, responsive to the Segment Type field and the FinalPayload Count Valid field, the data from the payload section.
 4. Theapparatus for transporting data of claim 3, wherein the contents of thepayload section comprise, responsive to the Final Payload Count Validfield, a Final Payload Count field, and wherein extracting the data fromthe payload section is further responsive to the Final Payload Countfield.
 5. A computer-readable data structure, encoded on acomputer-readable medium, for organizing data for transport, thestructure comprising: a frame comprising a header section, a payloadsection, and a trailer section; and wherein the header section comprisesa Segment Type field and a Final Payload Count Valid field, and whereinthe contents of the Segment Type field and the contents of the FinalPayload Count Valid field are responsive to the contents of the payloadsection.
 6. The computer-readable data structure for organizing data fortransport of claim 5, wherein the contents of the payload sectioncomprise, responsive to the Final Payload Count Valid field, a FinalPayload Count field.
 7. A computer data signal embodied in atransmission system, comprising: a frame for transporting data packetsin diverse formats through a transmission system, said frame comprisinga header section, a payload section, and a trailer section; and whereinthe header section comprises a Segment Type field and a Final PayloadCount Valid field, and wherein the contents of the Segment Type fieldand the contents of the Final Payload Count Valid field are responsiveto the contents of the payload section.
 8. The computer data signalembodied in a transmission system of claim 7, wherein the contents ofthe payload section comprise, responsive to the Final Payload CountValid field, a Final Payload Count field.
 9. A method for transportingdata, comprising: encapsulating data in a frame, wherein the framecomprises a first header section and a first payload section associatedwith the first header section, a second header section and a secondpayload section associated with the second header section, and a trailersection, and wherein the first header section comprises a First ServiceType field and the second header section comprises a Second Service Typefield, and wherein the first payload section contains a first portion ofthe data and the second payload section contains a second portion of thedata; setting, responsive to the first portion of the data, the FirstService Type field; setting, responsive to the second portion of thedata, the Second Service Type field; transporting the frame through acommunication system; extracting from the transported frame, responsiveto the First Service Type field, the first portion of the data from thefirst payload section; and extracting from the transported frame,responsive to the Second Service Type field, the second portion of thedata from the second payload section.
 10. An apparatus for transportingdata, comprising: means for encapsulating data in a frame, wherein theframe comprises a first header section and a first payload sectionassociated with the first header section, a second header section and asecond payload section associated with the second header section, and atrailer section, and wherein the first header section comprises a FirstService Type field, and the second header section comprises a SecondService Type Field, and wherein the first payload section contains afirst portion of the data, and the second payload section contains asecond portion of the data; means for setting, responsive to the firstportion of the data, the First Service Type field; means for setting,responsive to the second portion of the data, the Second Service Typefield; means for transporting the frame through a communication system;means for extracting from the transported frame, responsive to the FirstService Type field, the first portion of the data from the first payloadsection; and means for extracting from the transported frame, responsiveto the Second Service Type field, the second portion of the data fromthe second payload section.
 11. A computer-readable data structure,encoded on a computer-readable medium, for organizing data fortransport, the structure comprising: a frame comprising a first headersection and a first payload section associated with the first headersection, a second header section and a second payload section associatedwith the second header section, and a trailer section; and wherein thefirst header section comprises a First Service Type field and the secondheader section comprises a Second Service Type field, and wherein thecontents of the First Service Type field are responsive to the contentsof the first payload section, and the contents of the Second ServiceType field are responsive to the contents of the second payload section.12. A computer data signal embodied in a transmission system,comprising: a frame for transporting data packets in diverse formatsthrough a transmission system, said frame comprising a first headersection and a first payload section associated with the first headersection, a second header section and a second payload section associatedwith the second header section, and a trailer section; and wherein thefirst header section comprises a First Service Type field and the secondheader section comprises a Second Service Type field, and wherein thecontents of the First Service Type field are responsive to the contentsof the first payload section and the contents of the Second Service Typefield are responsive to the contents of the second payload section. 13.A method for transporting data, comprising: encapsulating data in aframe, wherein the frame comprises a header section, a payload section,and a trailer section, and wherein the header section comprises aRouting Identification field, and a Source Identification field, andwherein the payload section contains the data; setting, responsive to alogical frame routing connection, the Routing Identification field;setting, responsive to a frame origination location, the SourceIdentification field; transporting the frame through a communicationsystem; and extracting from the transported frame the data from thepayload section.
 14. An apparatus for transporting data, comprising:means for encapsulating data in a frame, wherein the frame comprises aheader section, a payload section, and a trailer section, and whereinthe header section comprises a Routing Identification field, and aSource Identification field, and wherein the payload section containsthe data; means for setting, responsive to a logical frame routingconnection, the Routing Identification field; means for setting,responsive to a frame origination location, the Source Identificationfield; means for transporting the frame through a communication system;and means for extracting from the transported frame the data from thepayload section.
 15. A computer-readable data structure, encoded on acomputer-readable medium, for organizing data for transport, thestructure comprising: a frame comprising a header section, a payloadsection, and a trailer section; and wherein the header section comprisesa Routing Identification field and a Source Identification field, andwherein the contents of the Routing Identification field are responsiveto a logical frame routing connection, and the contents of the SourceIdentification field are responsive to a frame origination location. 16.A computer data signal embodied in a transmission system, comprising: aframe for transporting data packets in diverse formats through atransmission system, said frame comprising a header section, a payloadsection, and a trailer section; and wherein the header section comprisesa Routing Identification field and a Source Identification field, andwherein the contents of the Routing Identification field are responsiveto a logical frame routing connection and the contents of the SourceIdentification field are responsive to a frame origination location.